1. Field of the Invention
The present invention relates to a primary server and a backup server that both support a RADIUS client and, more particularly, to an apparatus and method that provide a primary server and a backup server that both support a RADIUS client and share an IP address.
2. Description of the Related Art
The Remote Access Dial In User Service (RADIUS) protocol, which is described in Request for Comments (RFC) 2138, C. R. Livingston et al., April 1997, defines a procedure for sending authentication, authorization, and accounting information in a subscriber management system between a network access server executing RADIUS client software, and a remote authentication server executing RADIUS server software.
For example, the central office of a telephone company can include a network access server, known as a control module, which executes the RADIUS client software. The network access server is connected to a number of xDSL line cards in the central office which, in turn, are connected to customer premise equipment (CPE) at a number of customer premises. The CPE at a customer premise commonly includes an xDSL modem that is connected to an xDSL line card in the central office, and a personal computer that is connected to the xDSL modem.
The RADIUS client software includes a method that detects an authentication request. In the above example, a Point-to-Point Protocol (PPP) manager running on an xDSL line card can send an authentication request to the RADIUS client on the network access server in response to a request from a personal computer.
The RADIUS client detects the authentication request from the line card, and constructs a RADIUS authentication request packet that includes, for example, the user name and password. The RADIUS client assigns a message identifier (MID) to the authentication request, and then sends the RADIUS authentication request packet to the RADIUS server.
The MID is used to identify the authentication request information during processing, and the configuration data that is returned when the connection request is approved. Only a limited number of MIDs, such as 256, are available per internet protocol (IP) address with a RADIUS client.
The RADIUS server authenticates the user name and password, determines the level of service that the account is authorized to have, e.g., parental controls can vary the level of service, and then sends an authentication request accept packet, along with the configuration information that is needed to provide the service to the user, to the RADIUS client.
Alternately, if the RADIUS server is unable to authenticate the user name and password, the RADIUS server returns an authentication request reject packet back to the RADIUS client. In response, the RADIUS client sends the authentication results to the PPP manager on the line card.
In a fault-tolerant communications computing system, fault tolerance is often provided by utilizing a primary server with a backup server that takes over when the primary server fails. The primary server and the backup server can be configured a number of different ways, depending on how much information can be lost when the primary server fails.
In one approach, the primary server and the backup server are identical hardware systems that are run in parallel. In this case, both the primary and backup servers receive and process the same input data, but the output data of the backup server is discarded until the primary server fails. Although quite effective in providing redundancy, this approach tends to be expensive because of the amount of hardware duplication that is required.
In another approach, the primary server continuously updates the backup server on the tasks that the primary server is handling. In this approach, known as dynamic updating, when the primary server fails, the backup server can take over without losing data because the backup server is aware of the tasks being performed by the primary server.
One drawback of this approach, however, is that continuous updating scales poorly because as the number of updates increases, the overhead (the amount of the processing resources of the primary server consumed by the updates) increases as well. Thus, this approach is difficult to implement on a large-scale subscriber management system.
In a further approach, rather than continuously updating the backup server, the primary server periodically updates the backup server on the results of the tasks that the primary server is handling. Periodic notification requires less overhead to implement, but allows an amount of data to be lost. With periodic notification, when the primary server fails, data from the last update to the time of failure is lost.
In an additional approach, known as cold start, the primary server provides no updates to the backup server during normal operation. This “share nothing” approach is the least complex solution to implement, but the time required for the backup server to come up, which can be on the order of minutes, means that more data is lost as control moves from the primary server to the backup server. In some applications, however, the least complex solution is the preferred solution because the loss of data during this period can be tolerated.
FIG. 1 shows a block diagram that illustrates a conventional cold-start, RADIUS-based communications network 100. As shown in FIG. 1, communications network 100 includes a number of customer premises equipment (CPE) 110, e.g., a modem and personal computer (PC), an xDSL line card 112 that is connected to the CPE 110, and a network access system 114 that is connected to xDSL line card 112.
Network access system 114, in turn, includes a primary server 114A with a first IP address, and a backup server 114B with a second IP address that is connected to primary server 114A. Primary server 114A and backup server 114B both execute the RADIUS client software, and backup server 114B receives a failure signal FLS from primary server 114A when primary server 114A fails.
As further shown in FIG. 1, communications network 100 includes an authentication server (RADIUS server) 116 that is connected to the primary and backup servers 114A and 114B. RADIUS server 116 is a shared resource. As a result, RADIUS server 116 is connected to a large number of RADIUS clients in addition to servers 114A and 114B.
In operation, primary server 114A generates authentication request packets in response to a request, such as a request from a PPP manager running on xDSL line card 112, assigns a MID to the authentication request packets, and sends the packets to RADIUS server 116. RADIUS server 116 authenticates the user name and password, determines the level of service, and then sends the configuration information with the MID to primary server 114A.
When primary server 114A fails, primary server 114A sends the failure signal FLS to backup server 114B which, in turn, assumes control. Once backup server 114B has assumed control, backup server 114B generates authentication request packets in response to a request, assigns a MID to the authentication request packets, and sends the packets to RADIUS server 116.
One drawback of the approach illustrated in FIG. 1 is that the primary server and the backup server each require a separate IP address. Thus, there is a need for an apparatus and method that provide a primary server and a backup server that both support a RADIUS client and share an IP address.